Struct and bitfield strange behaviour





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







1















I am trying to modify bitfields in register. Here is my struct with bitfields defined:



struct GROUP_tag
{
...
union
{
uint32_t R;
struct
{
uint64_t bitfield1:10;
uint64_t bitfield2:10;
uint64_t bitfield3:3;
uint64_t bitfield4:1;
} __attribute__((packed)) B;
} __attribute__((aligned(4))) myRegister;
...
}

#define GROUP (*(volatile struct GROUP_tag *) 0x400FE000)


When I use the following line:



GROUP.myRegister.B.bitfield1 = 0x60;


it doesn't change only bitfield1, but bitfield2 as well. The register has value 0x00006060.



Code gets compiled to the following assembly code:



ldr r3,[pc,#005C]
add r3,r3,#00000160
ldrb r2,[r3,#00]
mov r2,#00
orr r2,#00000060
strb r2,[r3,#00]
ldrb r2,[r3,#01]
bic r2,r2,#00000003
strb r2,[r3,#01]


If I try with direct register manipulation:



int volatile * reg = (int *) 0x400FE160;
*reg = 0x60


the value of register is 0x00000060.



I am using GCC compiler.



Why is the value duplicated when I use struct and bitfields?



EDIT



I found another strange behaviour:



GROUP.myRegister.R = 0x12345678; // value of register is 0x00021212
*reg = 0x12345678; // value of register is 0x0004567, this is correct (I am programming microcontroller and some bits in register can't be changed)


My approach to change register value (with struct and bitfield) gets compiled to:



ldr r3,[pc,#00B4]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000078
strb r2,[r3,#0160]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000056
strb r2,[r3,#0161]
ldrb r2,[r3,#0162]
mov r2,#00
orr r2,#00000034
strb r2,[r3,#0162]
ldrb r2,[r3,#0163]
mov r2,#00
orr r2,#00000012
strb r2,[r3,#0163]









share|improve this question




















  • 1





    Probably unrelated (your code compiles, does it?), but register is a keyword in C, so you shouldn't ever use it as name.

    – Aconcagua
    Nov 22 '18 at 9:54











  • I renamed some variables in my code and forgot that register is a keyword. I edited the question. My code compiles.

    – Mark
    Nov 22 '18 at 9:58













  • What happens if you try GROUP.myRegister.B.bitfield2 = 0x60; ? Does bitfield1 also change ?

    – luci88filter
    Nov 22 '18 at 10:00











  • It produces very strange result. The value of register becomes 0x00818181.

    – Mark
    Nov 22 '18 at 10:09











  • @Mark Not that strange, 0x8181 is pretty close to 0x6060 left-shifted twice...

    – luci88filter
    Nov 22 '18 at 10:22


















1















I am trying to modify bitfields in register. Here is my struct with bitfields defined:



struct GROUP_tag
{
...
union
{
uint32_t R;
struct
{
uint64_t bitfield1:10;
uint64_t bitfield2:10;
uint64_t bitfield3:3;
uint64_t bitfield4:1;
} __attribute__((packed)) B;
} __attribute__((aligned(4))) myRegister;
...
}

#define GROUP (*(volatile struct GROUP_tag *) 0x400FE000)


When I use the following line:



GROUP.myRegister.B.bitfield1 = 0x60;


it doesn't change only bitfield1, but bitfield2 as well. The register has value 0x00006060.



Code gets compiled to the following assembly code:



ldr r3,[pc,#005C]
add r3,r3,#00000160
ldrb r2,[r3,#00]
mov r2,#00
orr r2,#00000060
strb r2,[r3,#00]
ldrb r2,[r3,#01]
bic r2,r2,#00000003
strb r2,[r3,#01]


If I try with direct register manipulation:



int volatile * reg = (int *) 0x400FE160;
*reg = 0x60


the value of register is 0x00000060.



I am using GCC compiler.



Why is the value duplicated when I use struct and bitfields?



EDIT



I found another strange behaviour:



GROUP.myRegister.R = 0x12345678; // value of register is 0x00021212
*reg = 0x12345678; // value of register is 0x0004567, this is correct (I am programming microcontroller and some bits in register can't be changed)


My approach to change register value (with struct and bitfield) gets compiled to:



ldr r3,[pc,#00B4]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000078
strb r2,[r3,#0160]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000056
strb r2,[r3,#0161]
ldrb r2,[r3,#0162]
mov r2,#00
orr r2,#00000034
strb r2,[r3,#0162]
ldrb r2,[r3,#0163]
mov r2,#00
orr r2,#00000012
strb r2,[r3,#0163]









share|improve this question




















  • 1





    Probably unrelated (your code compiles, does it?), but register is a keyword in C, so you shouldn't ever use it as name.

    – Aconcagua
    Nov 22 '18 at 9:54











  • I renamed some variables in my code and forgot that register is a keyword. I edited the question. My code compiles.

    – Mark
    Nov 22 '18 at 9:58













  • What happens if you try GROUP.myRegister.B.bitfield2 = 0x60; ? Does bitfield1 also change ?

    – luci88filter
    Nov 22 '18 at 10:00











  • It produces very strange result. The value of register becomes 0x00818181.

    – Mark
    Nov 22 '18 at 10:09











  • @Mark Not that strange, 0x8181 is pretty close to 0x6060 left-shifted twice...

    – luci88filter
    Nov 22 '18 at 10:22














1












1








1








I am trying to modify bitfields in register. Here is my struct with bitfields defined:



struct GROUP_tag
{
...
union
{
uint32_t R;
struct
{
uint64_t bitfield1:10;
uint64_t bitfield2:10;
uint64_t bitfield3:3;
uint64_t bitfield4:1;
} __attribute__((packed)) B;
} __attribute__((aligned(4))) myRegister;
...
}

#define GROUP (*(volatile struct GROUP_tag *) 0x400FE000)


When I use the following line:



GROUP.myRegister.B.bitfield1 = 0x60;


it doesn't change only bitfield1, but bitfield2 as well. The register has value 0x00006060.



Code gets compiled to the following assembly code:



ldr r3,[pc,#005C]
add r3,r3,#00000160
ldrb r2,[r3,#00]
mov r2,#00
orr r2,#00000060
strb r2,[r3,#00]
ldrb r2,[r3,#01]
bic r2,r2,#00000003
strb r2,[r3,#01]


If I try with direct register manipulation:



int volatile * reg = (int *) 0x400FE160;
*reg = 0x60


the value of register is 0x00000060.



I am using GCC compiler.



Why is the value duplicated when I use struct and bitfields?



EDIT



I found another strange behaviour:



GROUP.myRegister.R = 0x12345678; // value of register is 0x00021212
*reg = 0x12345678; // value of register is 0x0004567, this is correct (I am programming microcontroller and some bits in register can't be changed)


My approach to change register value (with struct and bitfield) gets compiled to:



ldr r3,[pc,#00B4]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000078
strb r2,[r3,#0160]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000056
strb r2,[r3,#0161]
ldrb r2,[r3,#0162]
mov r2,#00
orr r2,#00000034
strb r2,[r3,#0162]
ldrb r2,[r3,#0163]
mov r2,#00
orr r2,#00000012
strb r2,[r3,#0163]









share|improve this question
















I am trying to modify bitfields in register. Here is my struct with bitfields defined:



struct GROUP_tag
{
...
union
{
uint32_t R;
struct
{
uint64_t bitfield1:10;
uint64_t bitfield2:10;
uint64_t bitfield3:3;
uint64_t bitfield4:1;
} __attribute__((packed)) B;
} __attribute__((aligned(4))) myRegister;
...
}

#define GROUP (*(volatile struct GROUP_tag *) 0x400FE000)


When I use the following line:



GROUP.myRegister.B.bitfield1 = 0x60;


it doesn't change only bitfield1, but bitfield2 as well. The register has value 0x00006060.



Code gets compiled to the following assembly code:



ldr r3,[pc,#005C]
add r3,r3,#00000160
ldrb r2,[r3,#00]
mov r2,#00
orr r2,#00000060
strb r2,[r3,#00]
ldrb r2,[r3,#01]
bic r2,r2,#00000003
strb r2,[r3,#01]


If I try with direct register manipulation:



int volatile * reg = (int *) 0x400FE160;
*reg = 0x60


the value of register is 0x00000060.



I am using GCC compiler.



Why is the value duplicated when I use struct and bitfields?



EDIT



I found another strange behaviour:



GROUP.myRegister.R = 0x12345678; // value of register is 0x00021212
*reg = 0x12345678; // value of register is 0x0004567, this is correct (I am programming microcontroller and some bits in register can't be changed)


My approach to change register value (with struct and bitfield) gets compiled to:



ldr r3,[pc,#00B4]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000078
strb r2,[r3,#0160]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000056
strb r2,[r3,#0161]
ldrb r2,[r3,#0162]
mov r2,#00
orr r2,#00000034
strb r2,[r3,#0162]
ldrb r2,[r3,#0163]
mov r2,#00
orr r2,#00000012
strb r2,[r3,#0163]






c gcc assembly struct bit-fields






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 22 '18 at 11:20







Mark

















asked Nov 22 '18 at 9:36









MarkMark

586




586








  • 1





    Probably unrelated (your code compiles, does it?), but register is a keyword in C, so you shouldn't ever use it as name.

    – Aconcagua
    Nov 22 '18 at 9:54











  • I renamed some variables in my code and forgot that register is a keyword. I edited the question. My code compiles.

    – Mark
    Nov 22 '18 at 9:58













  • What happens if you try GROUP.myRegister.B.bitfield2 = 0x60; ? Does bitfield1 also change ?

    – luci88filter
    Nov 22 '18 at 10:00











  • It produces very strange result. The value of register becomes 0x00818181.

    – Mark
    Nov 22 '18 at 10:09











  • @Mark Not that strange, 0x8181 is pretty close to 0x6060 left-shifted twice...

    – luci88filter
    Nov 22 '18 at 10:22














  • 1





    Probably unrelated (your code compiles, does it?), but register is a keyword in C, so you shouldn't ever use it as name.

    – Aconcagua
    Nov 22 '18 at 9:54











  • I renamed some variables in my code and forgot that register is a keyword. I edited the question. My code compiles.

    – Mark
    Nov 22 '18 at 9:58













  • What happens if you try GROUP.myRegister.B.bitfield2 = 0x60; ? Does bitfield1 also change ?

    – luci88filter
    Nov 22 '18 at 10:00











  • It produces very strange result. The value of register becomes 0x00818181.

    – Mark
    Nov 22 '18 at 10:09











  • @Mark Not that strange, 0x8181 is pretty close to 0x6060 left-shifted twice...

    – luci88filter
    Nov 22 '18 at 10:22








1




1





Probably unrelated (your code compiles, does it?), but register is a keyword in C, so you shouldn't ever use it as name.

– Aconcagua
Nov 22 '18 at 9:54





Probably unrelated (your code compiles, does it?), but register is a keyword in C, so you shouldn't ever use it as name.

– Aconcagua
Nov 22 '18 at 9:54













I renamed some variables in my code and forgot that register is a keyword. I edited the question. My code compiles.

– Mark
Nov 22 '18 at 9:58







I renamed some variables in my code and forgot that register is a keyword. I edited the question. My code compiles.

– Mark
Nov 22 '18 at 9:58















What happens if you try GROUP.myRegister.B.bitfield2 = 0x60; ? Does bitfield1 also change ?

– luci88filter
Nov 22 '18 at 10:00





What happens if you try GROUP.myRegister.B.bitfield2 = 0x60; ? Does bitfield1 also change ?

– luci88filter
Nov 22 '18 at 10:00













It produces very strange result. The value of register becomes 0x00818181.

– Mark
Nov 22 '18 at 10:09





It produces very strange result. The value of register becomes 0x00818181.

– Mark
Nov 22 '18 at 10:09













@Mark Not that strange, 0x8181 is pretty close to 0x6060 left-shifted twice...

– luci88filter
Nov 22 '18 at 10:22





@Mark Not that strange, 0x8181 is pretty close to 0x6060 left-shifted twice...

– luci88filter
Nov 22 '18 at 10:22












1 Answer
1






active

oldest

votes


















4














Ah, I get it. The compiler is using strb twice to write the two least significant bytes to a Special Function Register. But the hardware is performing a word write (presumably 32 bits) each time, because byte writes to Special Function Registers are unsupported. No wonder it doesn't work!



As to how you can fix this, that depends on your compiler, and how much it knows about SFRs. As a quick and dirty fix, you can just use bit manipulation on R; instead of



GROUP.myRegister.B.bitfield1 = 0x60;


use e.g.



GROUP.myRegister.R = (GROUP.myRegister.R & ~0x3FF) | 0x60;


PS Another possibility: it looks like you have turned off optimisation (I see a redundant ldrb r2,[r3,#00] instruction in there). Perhaps if you turn it on, the compiler will come to its senses? Worth a try...



PPS Please change uint64_t to uint32_t. It's making my teeth hurt!



PPPS Come to think of it, that packed may be throwing the compiler off, causing it to assume that the bitfield struct may not be word-aligned (and thus forcing byte-by-byte acesss). Have you tried removing it?






share|improve this answer


























  • Removing __attribute__((packed)) solved the problem. Thank you!

    – Mark
    Nov 22 '18 at 12:32














Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53427820%2fstruct-and-bitfield-strange-behaviour%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









4














Ah, I get it. The compiler is using strb twice to write the two least significant bytes to a Special Function Register. But the hardware is performing a word write (presumably 32 bits) each time, because byte writes to Special Function Registers are unsupported. No wonder it doesn't work!



As to how you can fix this, that depends on your compiler, and how much it knows about SFRs. As a quick and dirty fix, you can just use bit manipulation on R; instead of



GROUP.myRegister.B.bitfield1 = 0x60;


use e.g.



GROUP.myRegister.R = (GROUP.myRegister.R & ~0x3FF) | 0x60;


PS Another possibility: it looks like you have turned off optimisation (I see a redundant ldrb r2,[r3,#00] instruction in there). Perhaps if you turn it on, the compiler will come to its senses? Worth a try...



PPS Please change uint64_t to uint32_t. It's making my teeth hurt!



PPPS Come to think of it, that packed may be throwing the compiler off, causing it to assume that the bitfield struct may not be word-aligned (and thus forcing byte-by-byte acesss). Have you tried removing it?






share|improve this answer


























  • Removing __attribute__((packed)) solved the problem. Thank you!

    – Mark
    Nov 22 '18 at 12:32


















4














Ah, I get it. The compiler is using strb twice to write the two least significant bytes to a Special Function Register. But the hardware is performing a word write (presumably 32 bits) each time, because byte writes to Special Function Registers are unsupported. No wonder it doesn't work!



As to how you can fix this, that depends on your compiler, and how much it knows about SFRs. As a quick and dirty fix, you can just use bit manipulation on R; instead of



GROUP.myRegister.B.bitfield1 = 0x60;


use e.g.



GROUP.myRegister.R = (GROUP.myRegister.R & ~0x3FF) | 0x60;


PS Another possibility: it looks like you have turned off optimisation (I see a redundant ldrb r2,[r3,#00] instruction in there). Perhaps if you turn it on, the compiler will come to its senses? Worth a try...



PPS Please change uint64_t to uint32_t. It's making my teeth hurt!



PPPS Come to think of it, that packed may be throwing the compiler off, causing it to assume that the bitfield struct may not be word-aligned (and thus forcing byte-by-byte acesss). Have you tried removing it?






share|improve this answer


























  • Removing __attribute__((packed)) solved the problem. Thank you!

    – Mark
    Nov 22 '18 at 12:32
















4












4








4







Ah, I get it. The compiler is using strb twice to write the two least significant bytes to a Special Function Register. But the hardware is performing a word write (presumably 32 bits) each time, because byte writes to Special Function Registers are unsupported. No wonder it doesn't work!



As to how you can fix this, that depends on your compiler, and how much it knows about SFRs. As a quick and dirty fix, you can just use bit manipulation on R; instead of



GROUP.myRegister.B.bitfield1 = 0x60;


use e.g.



GROUP.myRegister.R = (GROUP.myRegister.R & ~0x3FF) | 0x60;


PS Another possibility: it looks like you have turned off optimisation (I see a redundant ldrb r2,[r3,#00] instruction in there). Perhaps if you turn it on, the compiler will come to its senses? Worth a try...



PPS Please change uint64_t to uint32_t. It's making my teeth hurt!



PPPS Come to think of it, that packed may be throwing the compiler off, causing it to assume that the bitfield struct may not be word-aligned (and thus forcing byte-by-byte acesss). Have you tried removing it?






share|improve this answer















Ah, I get it. The compiler is using strb twice to write the two least significant bytes to a Special Function Register. But the hardware is performing a word write (presumably 32 bits) each time, because byte writes to Special Function Registers are unsupported. No wonder it doesn't work!



As to how you can fix this, that depends on your compiler, and how much it knows about SFRs. As a quick and dirty fix, you can just use bit manipulation on R; instead of



GROUP.myRegister.B.bitfield1 = 0x60;


use e.g.



GROUP.myRegister.R = (GROUP.myRegister.R & ~0x3FF) | 0x60;


PS Another possibility: it looks like you have turned off optimisation (I see a redundant ldrb r2,[r3,#00] instruction in there). Perhaps if you turn it on, the compiler will come to its senses? Worth a try...



PPS Please change uint64_t to uint32_t. It's making my teeth hurt!



PPPS Come to think of it, that packed may be throwing the compiler off, causing it to assume that the bitfield struct may not be word-aligned (and thus forcing byte-by-byte acesss). Have you tried removing it?







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 22 '18 at 12:11

























answered Nov 22 '18 at 11:47









TonyKTonyK

12.9k42560




12.9k42560













  • Removing __attribute__((packed)) solved the problem. Thank you!

    – Mark
    Nov 22 '18 at 12:32





















  • Removing __attribute__((packed)) solved the problem. Thank you!

    – Mark
    Nov 22 '18 at 12:32



















Removing __attribute__((packed)) solved the problem. Thank you!

– Mark
Nov 22 '18 at 12:32







Removing __attribute__((packed)) solved the problem. Thank you!

– Mark
Nov 22 '18 at 12:32






















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53427820%2fstruct-and-bitfield-strange-behaviour%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

鏡平學校

ꓛꓣだゔៀៅຸ໢ທຮ໕໒ ,ໂ'໥໓າ໼ឨឲ៵៭ៈゎゔit''䖳𥁄卿' ☨₤₨こゎもょの;ꜹꟚꞖꞵꟅꞛေၦေɯ,ɨɡ𛃵𛁹ޝ޳ޠ޾,ޤޒޯ޾𫝒𫠁သ𛅤チョ'サノބޘދ𛁐ᶿᶇᶀᶋᶠ㨑㽹⻮ꧬ꧹؍۩وَؠ㇕㇃㇪ ㇦㇋㇋ṜẰᵡᴠ 軌ᵕ搜۳ٰޗޮ޷ސޯ𫖾𫅀ल, ꙭ꙰ꚅꙁꚊꞻꝔ꟠Ꝭㄤﺟޱސꧨꧼ꧴ꧯꧽ꧲ꧯ'⽹⽭⾁⿞⼳⽋២៩ញណើꩯꩤ꩸ꩮᶻᶺᶧᶂ𫳲𫪭𬸄𫵰𬖩𬫣𬊉ၲ𛅬㕦䬺𫝌𫝼,,𫟖𫞽ហៅ஫㆔ాఆఅꙒꚞꙍ,Ꙟ꙱エ ,ポテ,フࢰࢯ𫟠𫞶 𫝤𫟠ﺕﹱﻜﻣ𪵕𪭸𪻆𪾩𫔷ġ,ŧآꞪ꟥,ꞔꝻ♚☹⛵𛀌ꬷꭞȄƁƪƬșƦǙǗdžƝǯǧⱦⱰꓕꓢႋ神 ဴ၀க௭எ௫ឫោ ' េㇷㇴㇼ神ㇸㇲㇽㇴㇼㇻㇸ'ㇸㇿㇸㇹㇰㆣꓚꓤ₡₧ ㄨㄟ㄂ㄖㄎ໗ツڒذ₶।ऩछएोञयूटक़कयँृी,冬'𛅢𛅥ㇱㇵㇶ𥄥𦒽𠣧𠊓𧢖𥞘𩔋цѰㄠſtʯʭɿʆʗʍʩɷɛ,əʏダヵㄐㄘR{gỚṖḺờṠṫảḙḭᴮᵏᴘᵀᵷᵕᴜᴏᵾq﮲ﲿﴽﭙ軌ﰬﶚﶧ﫲Ҝжюїкӈㇴffצּ﬘﭅﬈軌'ffistfflſtffतभफɳɰʊɲʎ𛁱𛁖𛁮𛀉 𛂯𛀞నఋŀŲ 𫟲𫠖𫞺ຆຆ ໹້໕໗ๆทԊꧢꧠ꧰ꓱ⿝⼑ŎḬẃẖỐẅ ,ờỰỈỗﮊDžȩꭏꭎꬻ꭮ꬿꭖꭥꭅ㇭神 ⾈ꓵꓑ⺄㄄ㄪㄙㄅㄇstA۵䞽ॶ𫞑𫝄㇉㇇゜軌𩜛𩳠Jﻺ‚Üမ႕ႌႊၐၸဓၞၞၡ៸wyvtᶎᶪᶹစဎ꣡꣰꣢꣤ٗ؋لㇳㇾㇻㇱ㆐㆔,,㆟Ⱶヤマފ޼ޝަݿݞݠݷݐ',ݘ,ݪݙݵ𬝉𬜁𫝨𫞘くせぉて¼óû×ó£…𛅑הㄙくԗԀ5606神45,神796'𪤻𫞧ꓐ㄁ㄘɥɺꓵꓲ3''7034׉ⱦⱠˆ“𫝋ȍ,ꩲ軌꩷ꩶꩧꩫఞ۔فڱێظペサ神ナᴦᵑ47 9238їﻂ䐊䔉㠸﬎ffiﬣ,לּᴷᴦᵛᵽ,ᴨᵤ ᵸᵥᴗᵈꚏꚉꚟ⻆rtǟƴ𬎎

Why https connections are so slow when debugging (stepping over) in Java?